Let's not forget to add this predicate in the validation pipeline.

I can kinda see the utility here, but what exactly is the use case?

I think maybe a more structured workspace-like approach would cover most of the uses for this for the "many projects that share some libraries" use case. Maybe this PR is the start of a feature like that?

it's for packages that are cloned locally in the manifest. Scryer isn't finding their scryer_lib folder unless I set the paths.

Concrete Use Case

Let me clarify with a real-world example I'm encountering.

Project Structure

I'm developing a project with this structure:

~/my-main-project/
  ├── scryer-manifest.pl
  ├── scryer_libs/          # Main project dependencies
  └── main.pl

~/programs/testing.pl/      # Local package I'm developing
  ├── scryer-manifest.pl
  ├── testing.pl
  └── scryer_libs/          # testing.pl's dependencies

~/programs/debug_indent/    # Another local package
  ├── scryer-manifest.pl  
  ├── debug_indent.pl
  └── scryer_libs/          # debug_indent's dependencies

The Manifest

My main project's scryer-manifest.pl references these local packages:

dependencies([
    dependency("testing", path("/home/jay/programs/testing.pl")),
    dependency("debug_indent", path("/home/jay/programs/debug_indent")),
    dependency("quads", git("https://github.com/jjtolton/quads.git", branch("master")))
]).

The Problem

When my code (or code in one of those local dependencies) tries to import a package with use_module(pkg(some_package)), bakage only searches in ~/my-main-project/scryer_libs.

But some packages I need are installed in:

• ~/programs/testing.pl/scryer_libs/
• ~/programs/debug_indent/scryer_libs/

Without scryer_path/1, these packages are invisible to bakage, and I get existence errors unless I manually set SCRYER_PATH environment variables.

The Solution

With scryer_path/1, I can declare:

scryer_path([
    "/home/jay/programs/testing.pl/scryer-manifest.pl",
    "/home/jay/programs/debug_indent/scryer-manifest.pl"
]).

Now bakage automatically searches for packages in all three locations:

1. ~/my-main-project/scryer_libs (default)
2. ~/programs/testing.pl/scryer_libs (from scryer_path)
3. ~/programs/debug_indent/scryer_libs (from scryer_path)

This is especially valuable for:

• Polyrepo development: Multiple related packages developed in parallel
• Monorepo-style projects: Shared libraries vendored locally without copying dependencies
• Editor compatibility: Declarative manifest-based paths instead of environment variables that editors might not propagate

This is just transitive dependencies! It's coming eventually, and this is definitely not the right way to do it.

Clarifying: with transitive dependencies this would just work.

Your main project would "inherit" and lock the dependencies of its dependencies recursively. You shouldn't need to refer to your dependencies' dependencies, that's what a package manager is for! This is why I still insist that Bakage is not ready for even early adoption yet, and why transitive dependencies are the biggest blocker for the MVP: a package manager is basically useless for any non-trivial use cases without them!

its been pretty useful to me! but sounds good I'll close this out and hack it in locally until then